Aminet 19/Aminet 19 (1997)(GTI - Schatztruhe)[!][Jun 1997].iso/Aminet/comm/tcp/AmiChatOrg1_3.lha/A.C.O./GalaxyNetPolicies.doc

Text File | 1996-11-22 | 14KB | 325 lines

==[ GalaxyNet IRC Network - Policy (rev. 3) ]=============================

The intent of this policy is not to create law. It's intended to be a
guideline for us to follow. But at the same time this policy shall
constitute the rules of operation on GalaxyNet.


*** Introduction *********************************************************

We must all remember the most important element of this network, the
users. Without them we might as well just down our servers and go back to
using another network. User rights shall be a paramount concern for all
of us.

Users must be treated with respect at all times. If there are any
personal problems between you and a specific user, /ignore or /silence
them. Never act irresponsible or immature. As an oper you represent all
of GalaxyNet. Ill behavior will result in the users not only disliking
you, but will change their attitude towards our whole network.


*** Committees **********************************************************

The governing body of GalaxyNet is divided into three groups. The
Administrators, the Network Committee (net-com) and the Channel Service
Committee (cservice-com).


* The Administrators:

The Administrators as a group shall have final authority in any matter.
Invoking this authority requires a vote of the administrators and a
simple majority will make the decision final. There are exceptions to
this which are defined later in this document.

Administrators should turn over any actions against another admin, oper
or user to the net-com for review. Administrators shall never pursue
action on their own.


* Committee voting:

The committees shall be panels of elected officials and shall consist of
five members or a total of 10% of all server administrators - whichever
number is greater.

To qualify for nomination the nominees must either be an administrator or
oper and must receive 2 nominations.

Committees shall be elected by accumulating the largest number of votes
from the administrators. For each nominee the administrators will vote yes
or no. The people with the largest number of yes votes shall be part of
the committee. In the event of a tie vote, the administrators shall vote
on the two or more individuals seperately.

The term of a committee member is 1 year.

Committee members may be removed by 4 administrators requesting the action.
A discussion period of 72 hours will take place on the admin list server
followed by a vote of the administrators. Removal requires a 60% majority.


* The Network Committee:

Net-com members shall investigate and/or mediate any difficulties on the
network. Should their recommendation be one of either removing of a server
or an oper, the recommendation is forwarded to all admins for a vote.

Committee members shall investigate continuous abuse by a user. They
may recommend to the Admins a user should receive a global kline. The
recommendation is forwarded to the admins for a vote.

The net-com shall investigate user complaints against any admin or oper.

Any complaints involving another admin, oper or global kline request
for a user shall be sent to the net-com for review. The committee shall
reach a decision within 72 hours. Include additional logs or other
documents with your complaint as well. Forged documentation will result
in immediate disposal of the complaint.

Should the committee reject your complaint, you shall have the right to
request a vote of the admins if 4 other admins are willing to support
your complaint.

The net-com will handle and take care of GalaxyNet's routing scheme,
decide where new servers will be linked, and keep track of the ircd
versions the servers are running. Servers not complying with net-com's
decisions without a valid reason may be juped or permanently delinked.
However, before the server is removed the situation will be discussed
and voted on by the Administrators. Temporary jupes may be set if the
server is a security risk to the rest of the network.

The Administrators shall have final say in any major net-com decision
using the voting process.


* The Channel Service Committee:

The cservice committee shall handle complaints and questions about the
Channel Service, the NickName Service and any registered channel.

The Committee members will handle new channel registration requests, and
investigate users or channels abusing the Channel Service. Continuing
abuse shall result in either the channel being set in NoOp mode, or the
Channel Service being removed from the channel. In the case of a user
abusing the Channel Service, his/her record may be disabled to prevent
further abuse.


*** Voting **************************************************************

To ensure each server has an equal vote only admins are eligible to
vote. This is 1 vote per admin. If an admin owns 2 or more servers
he/she shall be eligible for 1 vote only.  The goal here is to keep the
playing field level for everyone.

The only exception to voting eligibility shall be if an admin has been
recommended for removal. He/she shall not have the right to vote on that
action.

All major decisions shall be subject to vote, admins will have 72 hours
to vote.

These decisions shall include:

1) Forceful removal of a server (60% majority required)

2) Forceful removal of an oper (51% majority required)

3) Global Klines (60% majority required)


*** Server Code *********************************************************

No admin shall install a patch which increases vulnerability to the
network or that has an adverse effect on it. This includes ircd patches
that allow opers to perform mode changes without being a valid chanop, or
that circumvent channel bans.

All patches that are not part of the ircd-glx must be voted on before any
server may install them.

When a new ircd version is officially released, all servers must upgrade
within 30 days. Any servers that haven't upgraded after 30 days without
a valid reason may be temporarily juped or permanently delinked, depending
on the decision of net-com and the Administrators' voting results.


*** Channel Registration ************************************************

Users are limited to registering two channels each.

To register a channel you must have 3 supporting users. You can register
either via our www site, or by getting the registration form from
GalaxyBot (/msg GalaxyBot HELP). The cservice committee will verify the
supporters via email, and check the channel on IRC prior to registration.

Channel registration does not imply approval of your channel or its
contents. It's up to the channel owners to maintain legal content
on their channels. GalaxyNet shall not be liable for any actions on any
channel.


*** IRC Operator/Admin Guidelines ***************************************

Opers shall not get involved in channel politics at any time. Users will
fight, let them resolve their problems. We are not a police force. Should
the dispute involve a registered channel where someone has taken it over,
inform a member of the cservice committee or an administrator with access
to Pulsar's commands.

Opers are not to use channel services to give themselves ops, remove bans
on themselves or otherwise disrupt the operations of a channel. You are
only to use these functions when either a) you are requested to do so by
the owners of the channel, or b) in an extreme emergency that can't be
solved any other way. Abuse will be reprimanded appropriately.

Opers should not split their server from the rest of the network for
personal reasons. Servers should only be squited when they need to be
rerouted or to solve a net desynch.

Administrators are responsible to maintain their configuration in
accordance with network requirements. These requirements include U: lines,
H: lines and Q: lines. U: and Q: lines are not to be used without
approval. If a node poses an immediate danger to the stability of the
net the HUB may temporarily remove the c/n pair or add a Q: line. But,
the stability of the net must be at risk and you must have proof to this
effect. Leafs are not to add Q: lines under any condition.

You should /msg $servername prior to using /die. Allow your users a few
minutes to change servers prior to downing it. The same goes for rebooting
or rerouting the server. A server crash, understandably, will not give you
the chance to notify your users.

The /kill command should be used only if other methods do not work. Warn
the user first, if they persist then go ahead and kill them. You must put
a valid reason in the /kill comment. Idiot, lamer, twit, etc. are not
considered good kill comments and will probably get you a lot of msgs
from people asking what the kill was for.

* Reasons to /kill:

1 Clonebots (defined by more than 5 clients from the same host, run by the
  same user). If the clones keep coming back a local oper should add a K:
  line to stop the clones. If there are no local opers online at the time,
  or if the clonebots are on more than one server a temporary GLINE should
  be set for the appropriate hostmask.

  NOTE: There is a difference between clonebots and a user having more
  than one real connection (although it is unlikely anyone with over 5
  connections is actually using them all as real clients). If you are
  not sure something is a clone ask another oper for help.

2 Floodbots (these deserve instant death).

3 Persistent CTCP floods.

4 User requests you to kill his ghost. Make sure the hostmasks match,
  please.

* Reasons NOT to /kill:

1 A fight on a channel. It's not our place to get involved with channel
  politics. They have the ability to ban the user from the channel. It's
  not YOUR fight.

2 Someone calling you names. You have the option to use /ignore or
  /silence.

3 Any other reason not covered by Reasons to /kill.

Global K: lines (GLINEs) may only be set if the offending client(s) are on
more than one server, or if there is no local oper available to add a
kline. All admins online at the time must agree a GLINE is needed.

Should an IRC Operator be found to have abused/misused the commands
available to him/her, a ruling will be held by the net-com as to what
actions shall be taken to prevent another incident. It should be
stressed that NO ONE is to be excused from abuse of power, even if it
involves the admin of a server.


*** User behavior (includes admins and opers) ***************************

Users are not to flood under any circumstances. Violation of this will
usually result in a kline on the server. Persistent flooders may be
klined from the entire network.

Non-hostile bots are permitted. Bot policy varies from server to server so
check with the server admin prior to using his/her server for your bot.

Clonebots are prohibited and if you frequently launch clones you will find
yourself with a global kline. Clonebots are defined as more than 5 clients
from the same host, run by the same user. Our channel services will
auto-detect these and will not show any favoratism here.

If your script supports nethack protection turn it off. There is no reason
for it. GalaxyNet servers can't be used for netsplit hacks.


*** New server links ****************************************************

New servers must be announced to the operlist BEFORE they are linked.
If the server is not run by the admin of the machine, permission
must be obtained prior to announcing the link. If needed this can be
checked via email by the net-com. There will be a period of 72 hours for
anyone to ask questions or make complaints about the new link. If there
are no complaints, the Network Committee will decide who the new server
will get as their primary, secondary, and backup links. If there are
objections to connecting the new server the Administrators will vote on
whether to link it or not. There will be a 7-day voting dead line. A
majority (60%) of yes votes is needed to pass the new server application.

The new server will be evaluated for a period of 2 weeks. During this time
the server won't have voting privileges, but can still observe the voting
process via the operlist. The server will stay a leaf for the duration of
the evaluation period. One exception to this rule is a net merge, which is
further described below. If there are any complaints about the new server
after the evaluation period, the Administrators will vote on whether to
keep or disconnect the new link. The same rules apply as for the new
server application vote.


*** Net merges **********************************************************

Servers linking in as a group will be evaluated as a group, not on a
server-by-server basis. During the evaluation period the merging net
will stay linked as it were, with only one server connected to the
galaxynet HUBs at one time. This rule only applies to large networks that
will take a long time to integrate into the existing net. Networks
composed of less than 7 servers will be linked individually. If, after
the evaluation period, there are complaints about any of the new servers,
the Administrators will vote on whether to keep or disconnect the new
net. The same rules apply as for the new server application vote. If the
net merge passes the evaluation period the new servers will be divided
and linked in the best way possible. The Network Committee will take care
of this.


*** Server application form *********************************************

Server name:

Server location:

IRCD version:

Type of machine:

Operating system:

Memory available:

Bandwidth available:

Your full name:

IRC nickname:

Email address:

Ping and traceroute results to the nearest HUBs: (Ask on #outerlimits for
a current list of GalaxyNet HUBs)